efi: support updating multiple EFIs in mirrored setups (RAID1) #855

HuijingHei · 2025-02-18T13:35:51Z

Include 4 PRs to fix #132

efi: clarify function purpose by renaming validate_esp() to
validate_esp_fstype()

efi: extend support for run_update(), adopt_update(), and
validate() across all ESPs

BIOS: extend support for update & adopt_update on all devices

For dual boot, need to extend support for both.
Also add kola test to verify that supports updating multiple EFIs.

blockdev: Use /sysroot as fallback in get_devices() if
/boot is not mounted

Get pointer from #855 (comment)
If /boot is not mounted, the parent devices of /sysroot will
be used as a fallback.

champtar · 2025-03-15T23:58:23Z

src/efi.rs

+        if let Some(esp_device) = self.get_esp_device() {
+            esp_devices.push(esp_device.to_string_lossy().into_owned());
+        } else {
+            esp_devices = blockdev::find_colocated_esps("/").expect("get esp devices");
+        };


Have you considered / tried the case with 2 disks / 2 separate OS ? (we do that in our lab, 2 or even 3 rpm-ostree based OS, each one on one disk, all installed via anaconda)
I'm asking because quickly looking at the code, I would use find_colocated_esps("/") first and get_esp_device() as a fallback.

The safest might even be:

mounted ESP(s)

colocated ESP(s)

get_esp_device

If you have a bootc installed OS, and on a second disk an anaconda installed OS (not even ostree based), right now you are going to always pick the anaconda ESP

I would use find_colocated_esps("/") first and get_esp_device() as a fallback.

get_esp_device() will find CoreOS ESP label /dev/disk/by-partlabel/EFI-SYSTEM, or Anaconda ESP label /dev/disk/by-partlabel/EFI\\x20System\\x20Partition

find_colocated_esps("/") will list ESP partitions on the devices with mountpoint /boot, but it does not mean it is always mounted, for example, coreos does not mount esp after booted, see doc

Consider that on single disk, can easily get ESP label /dev/disk/by-partlabel/EFI-SYSTEM via get_esp_device(), but on multiple disks, it would be /dev/disk/by-label/esp-1 & /dev/disk/by-label/esp-2, does this make sense?

The safest might even be:

mounted ESP(s)
colocated ESP(s)
get_esp_device

What I did: when running update, get_esp_devices() would list the all esp devices, then in the loop device will check mounted ESP first, if not, will mount the esp then upgrade. I think you meant that need to check mounted firstly in the beginning, will try that, thanks!

Edit: For multiple disks, we still need the loop for each esp device. Will keep it as it is, WDYT?

get_esp_devices() would list the all esp devices

Maybe I don't understand rust code, but for me it first call get_esp_device() which returns 1 device based on a weak heuristic, if that fails then it tries to find multiple devices

Here 3 test cases, second OS (sdb) booted, running get_esp_devices():
sda: normal anaconda install
sdb: ESP not mounted, not using anaconda/coreos label
-> returns sda ?

sda: normal anaconda install
sdb & sdc: raid 1 mirrored, ESP not mounted, not using anaconda/coreos label
-> returns sda ?

sda: normal coreos install
sdb: also a coreos install, ESP not mounted
-> not sure which PARTLABEL wins, likely random at each boot

I do not have such env, but IMU, if second OS (sdb) booted, sda will not be mounted from the booted OS, in this case, we do not scan sda.

sda: normal anaconda install
sdb: ESP not mounted, not using anaconda/coreos label

skip sda, and get_esp_devices() will call find_colocated_esps("/") to find the mount point /boot device, then get ESP part on the same device

sda: normal anaconda install
sdb & sdc: raid 1 mirrored, ESP not mounted, not using anaconda/coreos label

skip sda, this is the case that we need to resolve actually, find_colocated_esps("/") to find the mount point /boot device which is /dev/md126, then need to get the backing devices list sdb & sdc and find ESP part on each device

sda: normal coreos install
sdb: also a coreos install, ESP not mounted

When I tried to boot VM with 2 coreos, failed with:

[ 9.373774] rdcore[957]: Error: System has 2 devices with a filesystem labeled 'boot': ["/dev/vdb3", "/dev/vda3"] [FAILED] Failed to start CoreOS Ignition Ensure Unique Boot Filesystem.

So we can skip this env.

I think I'm with @champtar on this one. I do think the code in find_colocated_esps() is a stronger heuristic since it doesn't rely on the labels.

For a36689b#r2000542257 - you are correct that you can't boot a system initially (i.e. Ignition boot) with multiple disks attached with the same boot/root filesystem labels, but there is nothing preventing you from first booting a system and then adding a disk later.

@HuijingHei you argue that sometimes /boot/ isn't mounted. Can we just say if /boot isn't mounted we'll find the parent devices of / (or target_root) and use that instead?

Can we just get rid of get_esp_device() if we move to find_colocated_esps()?

Agree that this makes sense, sorry for the above misunderstanding.
Can I do some check that if there is only 1 disk, then would call get_esp_device() ?

Can I do some check that if there is only 1 disk, then would call get_esp_device() ?

You could, but what would be the benefit?

I could see it being beneficial to make that optimization (and thus keep two separate code paths) if the performance was much different between one versus the other and this was an operation that ran often. In this case, though, this isn't something that runs often and I think it would be much better to just have a single code path that we maintain if it can satisfy all of our requirements.

SGTM, will update, thanks!

Can we just say if /boot isn't mounted we'll find the parent devices of / (or target_root) and use that instead?

Check that findmnt -J -v --output=SOURCE,FSTYPE,OPTIONS,UUID / will get "source": "composefs" (which is not real device), would use /sysroot instead and get "source": "/dev/vda4"

HuijingHei · 2025-04-07T14:21:33Z

@travier could you help to review when you have time? Thanks!

travier · 2025-04-09T17:37:01Z

Dusty added some logic in openshift/os#1795 about making sure that the ESP that we are finding are part of the same device that the one the /boot partition is in and we should do the same for both the RAID and non RAID case.

HuijingHei · 2025-04-10T03:07:53Z

Dusty added some logic in openshift/os#1795 about making sure that the ESP that we are finding are part of the same device that the one the /boot partition is in and we should do the same for both the RAID and non RAID case.

Agree, and what I did in this patch followed the same way.

src/bios.rs

dustymabe · 2025-04-15T19:42:38Z

src/efi.rs

+        if let Some(esp_device) = self.get_esp_device() {
+            esp_devices.push(esp_device.to_string_lossy().into_owned());
+        } else {
+            esp_devices = blockdev::find_colocated_esps("/").expect("get esp devices");
+        };


I think I'm with @champtar on this one. I do think the code in find_colocated_esps() is a stronger heuristic since it doesn't rely on the labels.

For a36689b#r2000542257 - you are correct that you can't boot a system initially (i.e. Ignition boot) with multiple disks attached with the same boot/root filesystem labels, but there is nothing preventing you from first booting a system and then adding a disk later.

@HuijingHei you argue that sometimes /boot/ isn't mounted. Can we just say if /boot isn't mounted we'll find the parent devices of / (or target_root) and use that instead?

Can we just get rid of get_esp_device() if we move to find_colocated_esps()?

dustymabe · 2025-04-15T20:03:30Z

src/efi.rs

+        let sysroot = sysroot.recover_path()?;
+
+        for esp_dev in esp_devices {
+            let dest_path = if let Some(dest_path) = self.check_mounted_esp(&sysroot)? {


I don't really understand why we needed to create a new check_mounted_esp() function (i.e. breaking up ensure_mounted_esp()). If we do really need this maybe we can split it into a separate commit with rationale?

IMO now when we call ensure_mounted_esp(&sysroot, &esp_dev) we should ensure that the esp_dev we passed in is the one that is mounted on the mountpoint. i.e. if somehow a different ESP is mounted there then we shouldn't be happy about it.

dustymabe · 2025-04-15T20:07:32Z

src/efi.rs

@@ -392,24 +434,37 @@ impl Component for Efi {
    }

    fn validate(&self, current: &InstalledContent) -> Result<ValidationResult> {
-        if !is_efi_booted()? && self.get_esp_device().is_none() {
+        let esp_devices = self.get_esp_devices();


we are calling get_esp_devices() multiple times. Perhaps we should run it once and store the data so that we aren't going through the same logic (and system calls) over and over again?

They are used in different subcommands, but agree that need to make the changes to store the data about <parent devices>, <bios_boot partitions>, <esp partitions>, a little tricky that they should be stored at runtime, any suggestions for this?

# mount -o remount,rw /boot && rm -f /boot/bootupd-state.json # bootupctl update -vvvv [TRACE bootupd] executing cli Running as unit: bootupd.service [TRACE bootupd] executing cli [TRACE bootupd::bootupd] No saved state [TRACE bootupd::bootupd] Remaining known components: 2 [DEBUG bootupd::blockdev] Find parent devices: ["/dev/vda"] [DEBUG bootupd::blockdev] Find bios_boot partitions: ["/dev/vda1"] [TRACE bootupd::component] Adoptable: ContentMetadata { timestamp: 2025-04-22T07:11:03.919Z, version: "42.20250422.20.0" } [DEBUG bootupd::blockdev] Find parent devices: ["/dev/vda"] [DEBUG bootupd::blockdev] Find esp partitions: ["/dev/vda2"] [TRACE bootupd::efi] No efivars mount at "/sys/firmware/efi/efivars" [TRACE bootupd::efi] No efivars mount at "/sys/firmware/efi/efivars" [TRACE bootupd::component] Adoptable: ContentMetadata { timestamp: 2025-04-22T07:11:03.919Z, version: "42.20250422.20.0" } [DEBUG bootupd::efi] Unmounting [DEBUG bootupd::blockdev] Find parent devices: ["/dev/vda"] [DEBUG bootupd::blockdev] Find bios_boot partitions: ["/dev/vda1"] [TRACE bootupd::component] Adoptable: ContentMetadata { timestamp: 2025-04-22T07:11:03.919Z, version: "42.20250422.20.0" } [DEBUG bootupd::blockdev] Find parent devices: ["/dev/vda"] [DEBUG bootupd::bios] Install grub modules on /dev/vda Adopted and updated: BIOS: grub2-tools-1:2.12-28.fc42.x86_64 [DEBUG bootupd::blockdev] Find parent devices: ["/dev/vda"] [DEBUG bootupd::blockdev] Find esp partitions: ["/dev/vda2"] [TRACE bootupd::efi] No efivars mount at "/sys/firmware/efi/efivars" [TRACE bootupd::efi] No efivars mount at "/sys/firmware/efi/efivars" [TRACE bootupd::component] Adoptable: ContentMetadata { timestamp: 2025-04-22T07:11:03.919Z, version: "42.20250422.20.0" } [DEBUG bootupd::blockdev] Find parent devices: ["/dev/vda"] [DEBUG bootupd::blockdev] Find esp partitions: ["/dev/vda2"] [DEBUG bootupd::efi] Mounted at "/boot/efi" [TRACE bootupd::efi] applying adoption diff: additions: 0 removals: 0 changes: 0 [TRACE bootupd::efi] Unmounted [DEBUG bootupd::efi] Unmounting Adopted and updated: EFI: grub2-efi-x64-1:2.12-28.fc42.x86_64,shim-x64-15.8-3.x86_64

Do experiments like change, initialize the parent devices at the beginning of update or adopt_and_update. Not sure if this is what we expect.

src/efi.rs

dustymabe · 2025-04-15T20:42:42Z

src/efi.rs

-            errs.push(format!("Removed: {}", f));
+        let esps = esp_devices.ok_or_else(|| anyhow::anyhow!("No esp device found!"))?;
+        let dest_root = Path::new("/");
+        for esp_dev in esps.iter() {


Since we now have multiple places where we basically need to iterate over esp_devices and mount them and then do_some_work() I wish there was an easy way just to make that a funcion and then yield like we can in python so that we don't have to copy/paste this same code in many places.

Do you know of way to do that? I did some searching around rust book and the net and didn't find an easy answer.

No, I can not find either.

is not mounted See pointer from coreos#855 (comment) If `/boot` isn't mounted we'll find the parent devices of `/sysroot` instead.

dustymabe · 2025-05-09T20:02:41Z

Is this ready for another round of review or are we waiting to rebase once #923 merges?

HuijingHei · 2025-05-12T05:43:24Z

Is this ready for another round of review or are we waiting to rebase once #923 merges?

Thank you for the asking! Yes, would be better to wait for #923 merge.

HuijingHei · 2025-05-22T03:22:10Z

Need #932 merge first.

`/boot` is not mounted Get pointer from coreos#855 (comment) If `/boot` is not mounted, the parent devices of `/sysroot` will be used as a fallback.

dustymabe · 2025-06-11T18:51:31Z

@HuijingHei let me know (ping me in matrix or slack) when you're ready for another round of code review on this one.

`/boot` is not mounted Get pointer from coreos#855 (comment) If `/boot` is not mounted, the parent devices of `/sysroot` will be used as a fallback.

HuijingHei · 2025-06-12T08:25:18Z

The CI is passed, I think it is ready to review now, thank you @dustymabe for the asking.
I have not yet tested this, but will do after reviewing.

dustymabe

Looks mostly good. A few small things.

I'll try to do some testing tomorrow when you've done a new push.

src/blockdev.rs

src/util.rs

src/bios.rs

`/boot` is not mounted Inspired by coreos#855 (comment) If `/boot` is not mounted, the parent devices of `/sysroot` will be used as a fallback.

`validate_esp_fstype()`

`validate()` across all ESPs

For dual boot, need to extend support for both. Also add kola test to verify that supports updating multiple EFIs.

`/boot` is not mounted Inspired by coreos#855 (comment) If `/boot` is not mounted, the parent devices of `/sysroot` will be used as a fallback.

dustymabe · 2025-06-13T21:46:28Z

I ran a test and it looked good:

Running as unit: bootupd.service; invocation ID: 9b0b15a403664ac9a2561744977df2e8                                                                                                    
Component EFI                                                                                                                                                                        
  Installed: grub2-efi-x64-1:2.06-6.fc35.x86_64,shim-x64-15.4-5.x86_64                                                                                                               
  Update: Available: grub2-efi-x64-1:2.12-28.fc42.x86_64,shim-x64-15.8-3.x86_64                                                                                                      
Detected: BIOS: 35.20211029.3.0                                                                                                                                                      
CoreOS aleph version: 35.20211029.3.0                                                                                                                                                
Boot method: BIOS                                                                                                                                                                    
[core@ibm-p8-kvm-03-guest-02 ~]$                                                                                                                                                     
[core@ibm-p8-kvm-03-guest-02 ~]$ sudo bootupctl update                                                                                                                               
Running as unit: bootupd.service                                                                                                                                                     
Previous EFI: grub2-efi-x64-1:2.06-6.fc35.x86_64,shim-x64-15.4-5.x86_64                                                                                                              
Updated EFI: grub2-efi-x64-1:2.12-28.fc42.x86_64,shim-x64-15.8-3.x86_64                                                                                                              
Adopted and updated: BIOS: grub2-tools-1:2.12-28.fc42.x86_64

and then ran the following:

sudo mount /dev/vda2 /boot/efi
find /boot/efi/ -type f | xargs sha256sum
sudo umount /boot/efi
echo
sudo mount /dev/vdb2 /boot/efi
find /boot/efi/ -type f | xargs sha256sum
sudo umount /boot/efi

to produce:

4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1  /boot/efi/EFI/fedora/shim.efi
4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1  /boot/efi/EFI/fedora/shimx64.efi
282a3b2872bebcf3d1ba42fe17c17ebe32a60759a20f058b5e960e542785fe82  /boot/efi/EFI/fedora/BOOTX64.CSV
83a49149f5a7060d0de43de3a0c683d99f3c58c418ab651ac9c254b4efaef0b8  /boot/efi/EFI/fedora/mmx64.efi
6bd05558dd681dd7bfc2d7b48fd8d6e634456a979f0da7bf92edf9900cbe9b59  /boot/efi/EFI/fedora/grubx64.efi
c8dc54611a495e6dd4c1e0535ae71ca105255340776aa1ebcb85c59e84523029  /boot/efi/EFI/fedora/grub.cfg
4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1  /boot/efi/EFI/BOOT/BOOTX64.EFI
e6ac4f6428bfd524bba6ccf69bef22538c1114e9ae3be23e084a4304df51064b  /boot/efi/EFI/BOOT/fbx64.efi

4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1  /boot/efi/EFI/fedora/shim.efi
4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1  /boot/efi/EFI/fedora/shimx64.efi
282a3b2872bebcf3d1ba42fe17c17ebe32a60759a20f058b5e960e542785fe82  /boot/efi/EFI/fedora/BOOTX64.CSV
83a49149f5a7060d0de43de3a0c683d99f3c58c418ab651ac9c254b4efaef0b8  /boot/efi/EFI/fedora/mmx64.efi
6bd05558dd681dd7bfc2d7b48fd8d6e634456a979f0da7bf92edf9900cbe9b59  /boot/efi/EFI/fedora/grubx64.efi
c8dc54611a495e6dd4c1e0535ae71ca105255340776aa1ebcb85c59e84523029  /boot/efi/EFI/fedora/grub.cfg
4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1  /boot/efi/EFI/BOOT/BOOTX64.EFI
e6ac4f6428bfd524bba6ccf69bef22538c1114e9ae3be23e084a4304df51064b  /boot/efi/EFI/BOOT/fbx64.efi

dustymabe · 2025-06-13T21:46:51Z

I can maybe run a more complicated test on Monday, but this is looking good to me.

dustymabe · 2025-06-14T13:13:03Z

I ran this test on UEFI too. I started on 35.20211119.3.0 CoreOS with a boot mirror:

$ cosa buildfetch --build=35.20211119.3.0 --artifact=qemu
$ cosa decompress --build=35.20211119.3.0

$ cat <<EOF > boot-mirror.bu
variant: fcos
version: 1.3.0
passwd:
  users:
    - name: core
      ssh_authorized_keys:
        - ...
      password_hash: ...
boot_device:
  layout: x86_64
  mirror:
    devices:
      - /dev/vda
      - /dev/vdb
EOF

$ cat boot-mirror.bu | butane --pretty --strict > boot-mirror.ign

$ cosa run --build=35.20211119.3.0 --memory 4096 \
    --devshell=false --ignition=boot-mirror.ign  \
    --usernet --ignition-direct --qemu-firmware=uefi --add-disk 10G

After it upgraded many times to get to Fedora 42 I then rebased to the
local build I did that included a locally compiled bootupd (and also
all the new static grub configs).

$ rpm-ostree rebase \
    ostree-unverified-image:oci-archive:/srv/fedora-coreos-42.20250613.dev.1-ostree.x86_64.ociarchive

After reboot I see:

Last login: Sat Jun 14 01:13:29 on ttyS0
Fedora CoreOS 42.20250613.dev.1
[core@localhost ~]$
[core@localhost ~]$
[core@localhost ~]$ sudo bootupctl status
Running as unit: bootupd.service; invocation ID: b514677308634928a14c0db311050994
Component EFI
  Installed: grub2-efi-x64-1:2.06-8.fc35.x86_64,shim-x64-15.4-5.x86_64
  Update: Available: grub2-efi-x64-1:2.12-28.fc42.x86_64,shim-x64-15.8-3.x86_64
Detected: BIOS: 35.20211119.3.0
CoreOS aleph version: 35.20211119.3.0
Boot method: EFI
[core@localhost ~]$
[core@localhost ~]$ sudo bootupctl update
Running as unit: bootupd.service
Previous EFI: grub2-efi-x64-1:2.06-8.fc35.x86_64,shim-x64-15.4-5.x86_64
Updated EFI: grub2-efi-x64-1:2.12-28.fc42.x86_64,shim-x64-15.8-3.x86_64
Adopted and updated: BIOS: grub2-tools-1:2.12-28.fc42.x86_64

And when I run this script:

sudo mount /dev/vda2 /boot/efi
find /boot/efi/ -type f | xargs sha256sum
sudo umount /boot/efi
echo
sudo mount /dev/vdb2 /boot/efi
find /boot/efi/ -type f | xargs sha256sum
sudo umount /boot/efi

I see:

4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1  /boot/efi/EFI/BOOT/BOOTX64.EFI
e6ac4f6428bfd524bba6ccf69bef22538c1114e9ae3be23e084a4304df51064b  /boot/efi/EFI/BOOT/fbx64.efi
4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1  /boot/efi/EFI/fedora/shim.efi
4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1  /boot/efi/EFI/fedora/shimx64.efi
83a49149f5a7060d0de43de3a0c683d99f3c58c418ab651ac9c254b4efaef0b8  /boot/efi/EFI/fedora/mmx64.efi
6bd05558dd681dd7bfc2d7b48fd8d6e634456a979f0da7bf92edf9900cbe9b59  /boot/efi/EFI/fedora/grubx64.efi
282a3b2872bebcf3d1ba42fe17c17ebe32a60759a20f058b5e960e542785fe82  /boot/efi/EFI/fedora/BOOTX64.CSV
d235bfc111d65f5cb1f8302fcdd38b08e2e1eaa9a2d1516fde97599a981d0f77  /boot/efi/EFI/fedora/grub.cfg

4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1  /boot/efi/EFI/BOOT/BOOTX64.EFI
e6ac4f6428bfd524bba6ccf69bef22538c1114e9ae3be23e084a4304df51064b  /boot/efi/EFI/BOOT/fbx64.efi
4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1  /boot/efi/EFI/fedora/shim.efi
4773d74d87c2371a25883b59a3b6d98d157de46933676706d215015b1130f2d1  /boot/efi/EFI/fedora/shimx64.efi
83a49149f5a7060d0de43de3a0c683d99f3c58c418ab651ac9c254b4efaef0b8  /boot/efi/EFI/fedora/mmx64.efi
6bd05558dd681dd7bfc2d7b48fd8d6e634456a979f0da7bf92edf9900cbe9b59  /boot/efi/EFI/fedora/grubx64.efi
282a3b2872bebcf3d1ba42fe17c17ebe32a60759a20f058b5e960e542785fe82  /boot/efi/EFI/fedora/BOOTX64.CSV
d235bfc111d65f5cb1f8302fcdd38b08e2e1eaa9a2d1516fde97599a981d0f77  /boot/efi/EFI/fedora/grub.cfg

Looks good to me.

dustymabe · 2025-06-14T13:14:54Z

One thing that might be an enhancement over what we have here is some indication in the normal output bootupctl status and bootupctl update that the software detects there are multiple devices under its control. i.e. when I run bootupctl status today I don't know from the output that it recognizes that or not.

dustymabe · 2025-06-14T13:15:18Z

One thing that might be an enhancement over what we have here is some indication in the normal output bootupctl status and bootupctl update that the software detects there are multiple devices under its control. i.e. when I run bootupctl status today I don't know from the output that it recognizes that or not.

This can be a followon PR though if we decide it's a good idea.

HuijingHei · 2025-06-16T03:00:20Z

One thing that might be an enhancement over what we have here is some indication in the normal output bootupctl status and bootupctl update that the software detects there are multiple devices under its control. i.e. when I run bootupctl status today I don't know from the output that it recognizes that or not.

This can be a followon PR though if we decide it's a good idea.

SGTM, thank you so much for the testing.

`/boot` is not mounted Inspired by #855 (comment) If `/boot` is not mounted, the parent devices of `/sysroot` will be used as a fallback.

HuijingHei force-pushed the efi-raid1 branch from ddb26d3 to d4bdbe1 Compare February 19, 2025 08:48

HuijingHei requested review from cgwalters and travier March 2, 2025 05:19

champtar reviewed Mar 15, 2025

View reviewed changes

HuijingHei mentioned this pull request Mar 24, 2025

Support updating multiple EFIs in mirrored setups (RAID1) #813

Closed

HuijingHei force-pushed the efi-raid1 branch 2 times, most recently from 8e26fda to 57d9de6 Compare April 3, 2025 14:01

HuijingHei mentioned this pull request Apr 9, 2025

[release-4.18] OCPBUGS-54594: update bootloader on aarch64 systems openshift/os#1795

Merged

dustymabe reviewed Apr 15, 2025

View reviewed changes

HuijingHei added the do-not-merge/work-in-progress label Apr 21, 2025

HuijingHei force-pushed the efi-raid1 branch 2 times, most recently from e649743 to 013b50d Compare April 22, 2025 07:31

HuijingHei force-pushed the efi-raid1 branch from 62dcbcc to 4f67591 Compare April 23, 2025 12:45

HuijingHei mentioned this pull request May 7, 2025

Add struct RootContext with devices #923

Merged

HuijingHei mentioned this pull request May 23, 2025

efi: rewrite ensure_mounted_esp() #932

Merged

HuijingHei force-pushed the efi-raid1 branch from 4f67591 to 5ec2b6a Compare June 1, 2025 04:10

openshift-ci bot removed the do-not-merge/work-in-progress label Jun 1, 2025

HuijingHei force-pushed the efi-raid1 branch 2 times, most recently from 7759604 to 3a6b3ad Compare June 2, 2025 12:04

HuijingHei force-pushed the efi-raid1 branch from 3a6b3ad to b3bfbdf Compare June 9, 2025 12:15

openshift-merge-robot added the needs-rebase label Jun 9, 2025

HuijingHei force-pushed the efi-raid1 branch from b3bfbdf to e64a6f3 Compare June 9, 2025 12:22

openshift-merge-robot removed the needs-rebase label Jun 9, 2025

HuijingHei force-pushed the efi-raid1 branch from e64a6f3 to 2202c70 Compare June 9, 2025 13:41

HuijingHei force-pushed the efi-raid1 branch 2 times, most recently from 2e8b2f4 to 7788bf2 Compare June 12, 2025 01:40

dustymabe reviewed Jun 12, 2025

View reviewed changes

src/blockdev.rs Show resolved Hide resolved

src/util.rs Outdated Show resolved Hide resolved

src/bios.rs Outdated Show resolved Hide resolved

src/bios.rs Outdated Show resolved Hide resolved

HuijingHei force-pushed the efi-raid1 branch from 7788bf2 to 87c7159 Compare June 13, 2025 01:44

HuijingHei added 4 commits June 13, 2025 17:05

efi: clarify function purpose by renaming validate_esp() to

0f9d1ac

`validate_esp_fstype()`

efi: extend support for update(), adopt_update(), and

923c594

`validate()` across all ESPs

BIOS: extend support for update & adopt_update on all devices

4c68027

For dual boot, need to extend support for both. Also add kola test to verify that supports updating multiple EFIs.

blockdev: Use /sysroot as fallback in get_devices() if

5222e9a

`/boot` is not mounted Inspired by coreos#855 (comment) If `/boot` is not mounted, the parent devices of `/sysroot` will be used as a fallback.

HuijingHei force-pushed the efi-raid1 branch from 87c7159 to 5222e9a Compare June 13, 2025 09:05

Remove unused functions

c9cd73e

dustymabe approved these changes Jun 14, 2025

View reviewed changes

dustymabe merged commit 57e0e29 into coreos:main Jun 16, 2025
12 checks passed

dustymabe pushed a commit that referenced this pull request Jun 16, 2025

blockdev: Use /sysroot as fallback in get_devices() if

059c56c

`/boot` is not mounted Inspired by #855 (comment) If `/boot` is not mounted, the parent devices of `/sysroot` will be used as a fallback.

HuijingHei deleted the efi-raid1 branch June 17, 2025 01:17

efi: support updating multiple EFIs in mirrored setups (RAID1) #855

efi: support updating multiple EFIs in mirrored setups (RAID1) #855

Uh oh!

Conversation

HuijingHei commented Feb 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

champtar Mar 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HuijingHei Mar 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HuijingHei Mar 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HuijingHei commented Apr 7, 2025

Uh oh!

travier commented Apr 9, 2025

Uh oh!

HuijingHei commented Apr 10, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HuijingHei Apr 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dustymabe commented May 9, 2025

Uh oh!

HuijingHei commented May 12, 2025

Uh oh!

HuijingHei commented May 22, 2025

Uh oh!

dustymabe commented Jun 11, 2025

Uh oh!

HuijingHei commented Jun 12, 2025

Uh oh!

dustymabe left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dustymabe commented Jun 13, 2025

Uh oh!

dustymabe commented Jun 13, 2025

Uh oh!

dustymabe commented Jun 14, 2025

HuijingHei commented Feb 18, 2025 •

edited

Loading

champtar Mar 15, 2025 •

edited

Loading

HuijingHei Mar 17, 2025 •

edited

Loading

HuijingHei Mar 17, 2025 •

edited

Loading

HuijingHei Apr 23, 2025 •

edited

Loading